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Transmitted herewith in triplicate is the APPEAL BRIEF in this application with respect to 
the Notice of Appeal received by The United States Patent and Trademark Office on June 30, 
2004. 

i 

I I Applicant(s) has previously claimed small entity status under 37 CFR § 1.27 . 

I I Applicant(s) by its/their undersigned attorney, claims small entity status under 37 
CFR§ 1.27 as: 

I I an Independent Inventor 

1 I a Small Business Concern 

I I a Nonprofit Organization. 

□ Petition is hereby made under 37 CFR § 1.136(a) (fees: 37 CFR § L17(a)(l)-(4) to 
extend the time for response to the Office Action of to and through 

comprising an extension of the shortened statutory period of month(s). 
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□ FOUR MONTH EXTENSION OF TIME 
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$1480 


$ 


□ FIVE MONTH EXTENSION OF TIME 


$1005 


$ 


$2010 


$ 


□ LESS ANY EXTENSION FEE ALREADY PAID 


minus 


($ ) 


minus 


($ ) 


TOTAL FEE DUE 




$0 




$330.00 


CxO The Commissioner is hereby requested to 


grant an 


extension 


of time 


for the 



appropriate length of time, should one be necessary, in connection with this filing or 
any future filing submitted to the U.S. Patent and Trademark Office in the above- 
identified application during the pendency of this application. The Commissioner is 
further authorized to charge any fees related to any such extension of time to Deposit 
Account 23-3050. This sheet is provided in duplicate. 

I I A check in the amount of $ .00 is attached. Please charge any deficiency or 

credit any overpayment to Deposit Account No. 23-3050. 

U<] Please charge Deposit Account No. 23-3050 in the amount of $330,00 . This sheet is 
attached in duplicate. 

1^1 The Commissioner is hereby requested to grant an extension of time for the 
appropriate length of time, should one be necessary, in connection with this filing or any 
future filing submitted to the U.S. Patent and Trademark Office in the above-identified 
application during the pendency of this application. The Commissioner is further authorized 
to charge any fees related to any such extension of time to deposit account 23-3050. This 
sheet is provided in duplicate. 
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Sir: 



APPELLANT'S BRIEF PURSUANT TO 37 C.F.R. § 1.192 

This brief is being filed in support of Appellant's appeal from the rejections of 
claims 1-23 dated April 1, 2004. A Notice of Appeal was filed on June 30, 2004. 
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REAL PARTY IN INTEREST 

UNISYS CORPORATION is the real party in interest in the present 
application. The inventor in the present application assigned his interest to UNISYS 
CORPORATION on October 10, 2001, as recorded by the United States Patent and 
Trademark Office ("USPTO") on October 15, 2001at reel 012272, frame 0583. 1 

RELATED APPEALS AND INTERFERENCES 

There are no related appeals or interferences. 

STATUS OF CLAIMS 

Claims 1-23 are pending in the present application. Claims 1, 12, and 18 
are the independent claims. In the Official Action dated April 1, 2004, claims 12-23 were 
rejected under 35 U.S.C. § 102(e) as allegedly anticipated by U.S. Patent No. 6,606,740 
Bl ("Lynn et al."). Claims 1-1 1 were rejected under 35 U.S.C § 103(a) as being 
allegedly obvious over Lynn et al. in view of U.S. Patent No. 5,729,747 ("Tsukakoshi"). 

Claims 1 -23 are reproduced in Appendix A, attached hereto, with an 
indication of status next to each claim, as of the date of this appeal. 

STATUS OF AMENDMENTS 

No Amendments to claims 1-23 have been made. The claims remain in the 
same form as originally filed with the application. 



1 Note that the original assignment document contained a typographical error in the 
application serial number. It referenced serial number 09/934,357 instead of 09/534,357. 
A corrected assignment with the proper serial number was executed by the inventor on 
May 22, 2002, and forwarded to the USPTO on June 2, 2002. 
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SUMMARY OF INVENTION 

There is often a disconnect between the language of the business people 
who envision software and the needs of the programmers who design and implement 
software. This disconnect may result in the software developers' failure to capture all of 
the "use cases" that may be helpful for users of software because the developers do not 
fully appreciate the nature of the business process that they will implement. A "use case" 
is an instance of the use of the software by an actor. Application 2, line 2. 

The present invention provides a method and tool for designing software. 
Application 3, line 7-8. First, a business plan for the software is specified. Next, one or 
more "focus areas" are identified. Application 3, line 9-10. Each focus area includes a 
set of "requirements" for the system. Application 3, lines 10-11. These requirements 
include a description of a process to be performed and any constraints on the manner in 
which the process is to be performed. Application 3, lines 11-14. The focus area also 
includes a set of "participants" who will interact with the specified process. Application 
3, lines 14-15. Each participant may have one or more identifiable "roles. " Application 
3, lines 15-16. 

The focus area may be decomposed into several "sub" focus areas. 
Application 3, line 20. Sub-focus areas are created by identifying aspects of the original 
focus area. Application 3, line 21-22. Each sub-focus area has a set of one or more 
participants. Application 3, line 25-26. Focus areas are decomposed recursively into 
lower and lower levels until each of the sub-participants (i.e., actors) in the tasks covered 
by the lowest level focus area has only one role. Application 4, line 2-4. A focus area 
where all of the participants have only one role is analogous to a "business use case," 
which may then be modeled by conventional means. Application 4, lines 4-6. 

ISSUES 

1. Whether claims 12-23 patentably define over U.S. Patent No. 6,606,740 
Bl ("Lynn et al") under 35 U.S.C. § 102(e). 
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2. Whether claims 1-11 patentably define over Lynn et al. in view of U.S. 
Patent No. 5,729,747 ("Tsukakoshi") under 35 U.S.C § 103(a). 

GROUPING OF CLAIMS 

Claims Rejected Under 102(e): The claims subject to the first contested 
ground of rejection, namely claims 12-23, rejected under 35 U.S.C. § 102(e), do not stand 
or fall together. Claims 12-23 can be divided into two separately patentable groups. 

Group 1: Claims 12, 15-18, and 21-23. 
Group 2: Claims 13-14 and 19-20. 
Claims Rejected Under 103(a): The claims subject to the second 
contested ground of rejection, namely claims 1-1 1, rejected under 35 U.S.C. § 103(a), do 
not stand or fall together. Claims 1-11 can be divided into two separately patentable 
groups. 

Group 3: Claims 1-2, and 11. 
Group 4: Claims 3-10 

ARGUMENT 

The following specifies the errors in the rejections under 35 U.S.C. § 
102(e) and 35 U.S.C § 103(a) and why the rejected claims are patentable under those 
respective sections, including the specific limitations in the rejected claims which are not 
described in the prior art of record. 

In general, the prior art relied upon includes two references: Lynn et al. 
and Tsukakoshi. Lynn et al. is relied upon to teach the majority of the elements in the 
independent claims. Tsukakoshi is relied upon only for teaching the step from claim 1 of 
"creating source code to perform acts performed in the course of providing said first 
subset of said business process". (Official Action, page 5). Applicant is willing to 
concede that the creation of source code to perform acts generally is well known in the 
art. Therefore, the following argument focuses primarily on the deficiency of Lynn et al. 
in supplying the other elements of claims 1-23. 
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The following argument first summarizes Lynn et al, and then sets forth 
the aspects of the claims that are not disclosed therein. 

Lynn et al 

Lynn et al. discloses a framework for developing a workflow processing 
system using object oriented design principles to minimize coding effort. See Lynn et al. 
column 2, lines 56-60. It provides a set of software objects, each uniquely performing a 
function in a workflow processing system. See Lynn et al. column 4, lines 52-54. The 
functionality provided by the objects is broad enough to apply to many different line of 
business applications. See Lynn et al. column 4, lines 64-66. Different applications and 
different users would utilize different subsets of the software objects to accomplish the 
work they are conducting. See Lynn et al. column 5, lines 62-65. 

The software structure disclosed in Lynn et al. is shown in Lynn et al. 
figure 2. The corresponding text, found from column 5, lines 8-51, states the following: 

The relationship between the objects in a workflow processing framework 
according to the present invention and the peripheral processes is illustrated in 
FIG 2. At the bottom level are conventional platforms 20... These 
conventional platforms 20 may run on any type of computer system... A set of 
foundation objects 22 access the conventional platforms 20 using standardized 
protocols whenever possible. . . 

The foundation objects 22 are illustrated separately from the objects 24 
providing common functions in support of different applications, because in a 
specific enterprise environment standardized protocols may not be available and 
the foundation objects may need to be modified to utilize conventional platforms 
20 existing in the enterprise environment or previously selected for use with the 
workflow processing system. . . 

The objects 24 providing common functions in support of different 
applications provide "foldering" of materials... used by each case and workflow 
function . . . Business processes 26 written in conventional programming 
languages perform enterprise specific functions . The business processes may 
be written in a variety of programming languages. . . 
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The above language from Lynn et al. demonstrates that the reference is directed to a 
general structure or framework for software, in which the bottom level is a conventional 
platform, the next level is a set of foundation objects, followed by objects providing 
common functions, and finally business processes. The notion of developing software by 
determining participants and associated roles is not present, and neither is a sub-focus 
area where each participant has only one single role. 

Rejection of Group 1 under 35 U.S.C. § 102(e) 
As stated above, claims 12, 15-18, and 21-23 were rejected under 35 
U.S.C. § 102(e) as allegedly anticipated by Lynn et al. Applicant respectfully disagrees 
with the grounds of rejection for at least the reasons set forth below. These claims have 
been separated into a first group under the 102(e) rejection. While the following 
arguments apply to all of the claims rejected under 102(e), claims 13-14 and 19-20 are 
considered separately allowable and will be specifically addressed in the next section. 

Rejections under 35 U.S.C. 102(e) require that the reference (or 
combination of references) disclose every element of the claim. According to the MPEP, 
"for anticipation under 35 U.S.C. 102, the reference must teach every aspect of the 
claimed invention either explicitly or impliedly." MPEP § 706.02. Lynn et al. does not 
disclose at least one aspect of claims 12-23. Independent claim 12 provides: 

12. A method for providing computer-assisted software engineering 
comprising: 

receiving first information indicative of a first focus area, said 
first focus area representing: 

a set of first requirements for software to be developed; 

and 

a set of first participants in the use of said software; 
receiving a division of said set of first requirements which 
indicates a plurality of separate first aspects of said set of first 
requirement; 

displaying said set of first requirements and said set of first 
participants; 

receiving second information indicative of a second focus area, 
said second focus area including: 
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a set of second requirements for a one of said first 

aspects; and 

a set of second participants who participate in a use of 
said one of said first aspects, said second set of participants being based on 
said first set of participants; 

receiving a division of said set of second requirements which 
indicates a plurality of separate second aspects of said set of second 
requirements; 

displaying said set of second requirements and said set of second 
participants; 

receiving third information which includes: 

a set of third requirements for a one of said second 

aspects; and 

a set of third participants who participate in a use of said 
one of said second aspects, each of said third participants having only a 
single role with respect to said one of said second aspects; and 

generating a use case based on said third information, said use case 
defining an instance of the operation of said software by a one of said third 
participants participating in said one of said second aspects. 



(emphasis added). Generally referring to the bolded text above, claim 12 requires 
receiving first information, second information, and third information. Each item of 
information includes: 1. requirements; and, 2. participants. In addition, the first, second, 
and third information items are related to one another. To clearly understand some the 
relationships between the informations in claim 12, see the figure below. 
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Claim 12 

The above illustration can be understood by referring to the language of 
claim 12. In short, each of three informations includes: 1. requirements; and, 
2. participants. The requirements of the second information are directed to one of the 
aspects of the first information (as illustrated, aspect 1). The participants of the second 
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information participate in a use of this same aspect, i.e. the aspect of the first information 
for which further requirements are specified in the second information. Likewise, the 
requirements of the third information are directed to one of the aspects of the second 
information (as illustrated, aspect 4). Again, participants of the third information 
participate in a use of this same aspect — the aspect of the requirements of the second 
information for which further requirements are specified in the third information. 
Finally, the third participants have only a single role with respect to an aspect (as 
illustrated, aspect 4). 

There are a multitude of limitations in claim 12 that are simply not present 
in Lynn et al. However, because a reference is deficient if it lacks only one limitation of 
the claim, this response will focus on the failure of Lynn et al. to teach "each of said third 
participants having only a single role with respect to said one of said second aspects" 
See claim 12, above. Lynn does not disclose limiting participants to a single role in any 
context, whether with regard to an aspect of requirements for software or otherwise. 

A role is defined in the specification for the present invention beginning 
on Application 11, last paragraph. "A role represents the behavior of a participant. . .with 
respect to an aspect of a business process. . .[A] professor can be both an event scheduler 
and an invitee to an event. These roles are separate and distinct with respect to the 
overall business process in the sense that, when a professor schedules an event, he 
behaves differently with respect to the software. . .than he would behave if he were 
receiving an invitation to an event." 

The Official Action cites Lynn et al. Fig. 3 as disclosing the limitation in 
question. This figure presents a series of boxes labeled "business processes 26," and a 
series of boxes labeled "objects 24." Both "business processes" and "objects" are 
software. See Lynn et al. 5:42-5:43 ("objects providing support of different 
applications"); Lynn et al. 5:47-5:48 (Business processes written in conventional 
programming languages. . ."). The notion of a participant in the use of such software is 
absent from Lynn et al. Fig. 3. Perhaps more importantly, Lynn et al. does not disclose, 
in Fig. 3 or elsewhere, limiting a participant to a single role. 
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Applicant acknowledges that various portions of Lynn et al. refer to 
"users." See, e.g., Lynn et al. 5:62-5:65 ("Different applications and different users 
would utilize different subsets of the business processes, common objects, foundation 
objects and conventional platforms."); 6:37-6:39 ("The user assignment module provides 
balanced distribution of work based on each user's load factor stored in a database 
table."). However, the "users" of Lynn et al. are not equivalent to the "participants" of 
Applicant's invention. This is because participants are represented in a first focus area in 
a method for providing computer assisted software engineering. See claim 12. Thus, 
"participants" of the invention, while they may correspond to physical people, are 
actually an entity represented in data as part of designing software. In contrast, the 
"users" of Lynn et al. are simply those for whom the software is designed, just as most 
software is designed for use by users. 

Even if the "users" were considered equivalent to "participants," there is 
no teaching in Lynn et al. that the users are limited to a single role in using the system 
provided in Lynn. Therefore, Applicant respectfully maintains that the Examiner has not met 
his burden in providing a reference or combination of references that contain all the elements of 
the claims. Specifically, Applicant cannot find, in the references relied upon or other references 
of record, participants having only a single role in using the software of the system. 

In view of the foregoing, it is respectfully submitted that independent 
claim 12 is patentable over Lynn et al. As claims 15-17 depend either directly or 
indirectly from claim 1, they are believed allowable for the same reasons. Withdrawal of 
the rejections under 35 U.S.C § 102(e) is thus earnestly solicited. 

Claim 18 contains identical structure to claim 12, differing only in the 
preamble. In claim 12, the preamble is directed to a method, and in claim 18 the 
preamble is directed to a computer-readable medium. Because of the otherwise identical 
structure, it is respectfully submitted that independent claim 1 8 is also patentable over 
Lynn et al. As claims 21-23 depend either directly or indirectly from claim 18, they are 
believed allowable for the same reasons. Reversal of the rejections under 35 U.S.C 
§ 102(e) is thus earnestly solicited. 
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Rejection of Group 2 under 35 U.S.C. § 102(e) 
Claims 13-14 and 19-20 were also rejected under 35 U.S.C. § 102(e) as 
allegedly anticipated by Lynn et al. Applicant respectfully disagrees with the grounds of 
rejection for at least the reasons set forth below. Note that while claims 13-14 and 19-20 
are considered separately allowable and will be specifically addressed in this section, the 
arguments set forth above apply to independent claims 12 and 18 and therefore dependent 
claims 13-14 and 19-20 are also allowable for the reasons in the above section. 

Rejections under 35 U.S.C. 102(e) require that the reference (or 
combination of references) disclose every element of the claim. According to the MPEP, 
"for anticipation under 35 U.S.C. 102, the reference must teach every aspect of the 
claimed invention either explicitly or impliedly." MPEP § 706.02. Lynn et al. does not 
disclose at least one aspect of claims 13-14 and 19-20. Dependent claims 13 and 14 
provide: 

13. The method of claim 12, further comprising: 

providing a template which comprises a requirements field and 
a participants field; 

and wherein said act of receiving first information comprises: 

storing said set of first requirements in said requirements 

field; and 

storing said set of first participants in said participants 

field; 

and wherein said act of receiving second information comprises: 

storing said set of second requirements in said requirements 

field; and 

storing said set of second participants in said participants 

field; 

and wherein said act of receiving third information comprises: 

storing said set of third requirements in said requirements 

field; and 

storing said set of third participants in said participants 

field. 

14. The method of claim 12, wherein said method further comprises: 

providing a template which comprises a plurality of fields 
which represent a use case; 

and wherein said generating act comprises: 
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displaying said template with at least some of said plurality 
of fields containing information which is based on said third information. 

Both of the above claims recite a template. Claim 1 3 additionally recites a 
requirements field and a participants field, while claim 14 additionally recites a plurality 
of fields which represent a use case. 

Turning first to claim 13, the Official Action finds the emphasized element 

above in Lynn et al. 12:1 1. Official Action 3. That section of Lynn et al. provides: 

[A] letter generation wizard is preferably included to provide. . .the 
creation of a custom letter. The letter generation wizard interfaces with a 
work processing program in the convention al platforms 20, such as 
Microsoft Word. It allows the user to select form a list of letter templates. 
Once a letter template is selected, the wizard reads the template in, e.g., 
Microsoft Work, for each bookmark and displays the bookmarks in a 
window for the window for the user to fill in. The wizard replaces the 
bookmark values with the provided values and sizes the fields according 
to user defined size configurations for each field. 

Lynn et al. 12:4-12:16. While the term "template" is indeed used here, the template 
described otherwise bears little resemblance to the template of claims 13 and 14. There is 
no mention of a requirements field or of a participants field in Lynn et al. 

The template provided by claim 13 encourages a development team to 
think in terms of the focus areas and participants provided by the independent claims. See 
Application 32, line 25-30. Second, fields in a template can be selected to "propagate" to 
a sub-focus area. Application 33, line 1-3. The template thus provides a tool for 
facilitating the use of the invention described in the independent claims. 

Moreover, the template in Lynn et al. is for creating a letter, while the 
template of claims 13 and 14 is for creating computer software. As stated in the 
specification: "One advantage to using a template with such fields is that doing so allows 
a software development team to organize its analysis of a business process into various 
areas." Application 32. The words "such fields" in this sentence refer, in part, to the 
fields in Tables 1-4. Table 1 is set forth on Application 15, and includes the fields "focus 
area name," "ID," "Project," Release," and so forth. These are not the fields of a letter 
template, but rather those of a software design template. 
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Claim 19 is analogous to claim 13, differing only in the preamble. 
Therefore claim 19 is also considered allowable for the reasons set forth above. 

Turning next to claim 14, the Official Action also finds the emphasized 
element from claim 14, above, in Lynn et al. 12:11. Official Action 3. Referring to the 
quotation of Lynn et al. 12:4-12:16, above, applicant fails to see how the recital of the 
term "template" in the context of a letter generation wizard anticipates "providing a 
template which comprises a plurality of fields which represent a use case." 

A use case, as that term is defined in the specification at Application 2, 
line 2, is an instance of the use of software by an actor. Application 2, line 2. Application 
21-25 provides a table with exemplary use case specification attributes that could be 
included in a template as contemplated by claim 14. Some of the fields are "Use Case 
Name," "Use Case ID," "Project," "Phase," "Release," and so on. These are not the fields 
in a letter template, but rather those of a template for software development 

Claim 20 is analogous to claim 14, differing only in the preamble. 
Therefore claim 19 is also considered allowable for the reasons set forth above. 

Rejection of Group 3 under 35 U.S.C. § 103(a) 
Claims 1, 2 and 1 1 were rejected under 35 U.S.C § 103(a) as being 
allegedly obvious over Lynn et al. in view of Tsukakoshi. These claims have been 
separated into a first group under the 103(a) rejection. While the following arguments 
apply to all of the claims rejected under 103(a), claims 3-10 are considered separately 
allowable and will be specifically addressed in the next section. 

As with rejections under 35 U.S.C. 102(e), rejections under 35 U.S.C. 
103(a) require that the reference (or combination of references) disclose every element of 
the claim. As stated in the MPEP, "the prior art references (or references when 
combined) must teach or suggest all the claim limitations." MPEP § 706.02(j). Also, 
"[ojbviousness can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either explicitly or implicitly in the references themselves or in 
the knowledge generally available to one of ordinary 'skill in the art." MPEP 2143.01. 
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The references are similarly deficient with regard to claims 1, 2, and 11, 
again because at least one element of these claims is not present in either Lynn et al. or 
Tsukakoshi. Independent claim 1 provides: 

1 . A method for developing software, the method comprising: 
defining a focus area which represents: 

a business process to be performed by the software under development; and 

one or more first participants in said business process, at least one of said first 
participants having a plurality of roles; 

decomposing said focus area into one or more sub-focus areas , each of said sub- 
focus areas including: 

a subset of said business process ; and 

one or more second participants in said subset of said business process, each of 
said second participants having only a single one of said plurality of roles ; 

creating a use case based on a first one of said one or more sub-focus areas, said 
use case comprising an instance of usage, by a one of said second participants, of a first 
subset associated with said first one of said sub-focus areas; and 

creating source code to perform acts performed in the course of providing said 
first subset of said business process. 

(Emphasis added). Generally referring to the bolded text of the claim, a focus area and a 
sub-focus area are provided. Each of these has 1 . a business process or a subset thereof, 
and 2. participants. 

As with claim 12, there are a multitude of limitations in claim 1 that are 
simply not present in Lynn et al. or Tsukakoshi. However, because a reference is 
deficient if it lacks only one limitation of the claim, this response will focus on the failure 
of Lynn et al. to teach "each of said second participants having only a single one of said 
plurality of roles." See claim 1, above. Neither Lynn et al. nor Tsukakoshi discloses 
limiting participants to a single role in any context, whether with regard to business 
processes or otherwise and, in fact, the Examiner only cites Tsukakoshi for teaching the 
step of "creating source code to perform acts performed in the course of providing said 
first subset of said business process". (Official Action, p. 5) 

Participant roles are defined in the specification as explained above with 
regard to claim 12. Again, "A role represents the behavior of a participant. . .with respect 
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to an aspect of a business process" Application 11, last paragraph. In rejecting claims 1- 
11, the Official Action does not cite any further portions of Lynn et al. or Tsukakoshi that 
suggest limiting participants to a single role. The Official Action cites Lynn et al. 3:15- 
3:17, which reads in full as follows: 

[A] database, accessed by a subset of said software objects, defining work 
taxonomy and work steps for workflow processing; and a workflow 
engine utilizing said software objects and the work taxonomy to perform 
the workflow processing. 

This language discloses software objects accessing a database, and a workflow engine 
utilizing software objects, but it does not suggest "participants having only a single one. . . 
roles." See claim 1. 

As neither Lynn et al. nor Tsukakoshi discloses or suggests the 
aforementioned limitation, whether taken alone or in combination, it is respectfully 
submitted that independent claim 12 is patentable over the cited art. As claims 2 and 1 1 
depend either directly or indirectly from claim 1, they are believed allowable for the same 
reasons. Reversal of the rejections under 35 U.S.C § 103(a) is thus earnestly solicited. 

Rejection of Group 4 under 35 U.S.C. § 103(a) 

Claims 3-10 were also rejected under 35 U.S.C. § 103(a) as allegedly 
obvious over Lynn et al in view of Tsukakoshi. Applicant respectfully disagrees with the 
grounds of rejection for at least the reasons set forth below. Note that while claims 3-10 
are considered separately allowable and will be specifically addressed in this section, the 
arguments set forth above apply to independent claim 1 and therefore dependent claims 
3-10 are also allowable for the reasons in the above section. 

Rejections under 35 U.S.C. 103(a) require that the reference (or 
combination of references) disclose every element of the claim. As stated in the MPEP, 
"the prior art references (or references when combined) must teach or suggest all the 
claim limitations." MPEP § 706.02(j). Also, "[o]bviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either explicitly or 
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implicitly in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art." MPEP 2143.01. The combination of Lynn et al. and Tsukakoshi 
fails to disclose at least one aspect of claims 3-10. Dependent claim 3 provides: 

3. (Original) The method of claim 1, wherein said focus area is 
represented as a specification including a plurality of fields, and wherein 
said method further comprises: 

propagating one or more of said plurality of fields to each of 
said sub-focus areas; and 

creating, for each of said sub-focus areas, a set of fields based on 
the one or more propagated fields. 

An exemplary "specification including a plurality of fields" can be found 
at Application 15-18 (Table 1). Any of the exemplary fields referred to in Table 1 can be 
propagated to "each of said sub-focus areas." The definition of "propagate" is as follows: 
1. To cause (an organism) to multiply or breed. 2. To breed (offspring). 3. To transmit 
(characteristics) from one generation to another. American Heritage College Dictionary 
1116 (2002). Because fields are not organisms, we can conclude that the (an organism) 
parenthetical does not apply, and that the fields are caused to multiply, i.e. additional 
copies or references to the field are made, and that these additional copies or references 
are then placed in a sub-focus area. 

The Official Action maintains that the emphasized element of claim 3, 
above, is present in Lynn et al. Official Action 6. Specifically, the Official Action 
maintains that Lynn et al. FIG 4A, elements 80, 82, and 83 provide a propagation of 
fields. Referring to that Figure, a first box 80, which appears to be a plurality of boxes, is 
labeled BLWFWorkListFields. A line is traced down from this box to another box 82 
labeled BLWFWorkListField. The examiner has apparently concluded from this Figure, 
showing plural boxes connected to a singular box, that "propagating" is illustrated. 

The Lynn et al specification, however, demonstrates that this is a mistaken 
conclusion: "BLCaseWorkList 62 calls a collection of objects named 
BLWFWorkListFields 80 formed of objects named BLWFWorkListField. Lynn et al. 
8:28-8:30. Therefore, Lynn et al.'s Fig. 4 is referring to objects, not fields, and there is no 
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propagation, but rather a plurality of single objects that combine to form plural objects. 
The act of propagating, or multiplying, is not present. 



Claims 4-10 are each dependent upon claim 3. Therefore claims 4-10 are 



also considered allowable over Lynn et al. and Tsukakoshi for the reasons set forth 
above. 

CONCLUSION 



Applicant believes that the present reply is responsive to each of the points 



raised by the Examiner in the outstanding Official Action, and submits that Claims 1-23 
of the application are in condition for allowance. For all the foregoing reasons, Appellant 
respectfully requests that the Board reverse the rejection of claims 1-23. 



Woodcock Washburn LLP 
One Liberty Place - 46th Floor 
Philadelphia PA 19103 
Telephone: (215) 568-3100 
Facsimile: (215)568-3439 



Respectfully submitted, 



Date: August 30, 2004 




Nathaniel Ari Long 
Registration No. 53,233 
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APPENDIXA 
Claims on Appeal 

1. (Original) A method for developing software, the method comprising: 

defining a focus area which represents: 

a business process to be performed by the software under development; 

and 

one or more first participants in said business process, at least one of said 
first participants having a plurality of roles; 

decomposing said focus area into one or more sub-focus areas, each of said sub- 
focus areas including: 

a subset of said business process; and 

one or more second participants in said subset of said business process, 
each of said second participants having only a single one of said plurality of roles; 

creating a use case based on a first one of said one or more sub-focus areas, said 
use case comprising an instance of usage, by a one of said second participants, of a first 
subset associated with said first one of said sub-focus areas; and 

creating source code to perform acts performed in the course of providing said 
first subset of said business process. 

2. (Original) The method of claim 1, wherein said decomposing step comprises: 

decomposing said first focus area into an intermediate-level focus area which 
includes: 

a subset of said business process; and 

one or more third participants, at least one or more of said third 
participants having more than one of said plurality of roles; and 

further decomposing said intermediate-level focus area to produce a second one 
of said sub-focus areas. 

3. (Original) The method of claim 1, wherein said focus area is represented as a 
specification including a plurality of fields, and wherein said method further comprises: 
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propagating one or more of said plurality of fields to each of said sub-focus areas; 

and 

creating, for each of said sub-focus areas, a set of fields based on the one or more 
propagated fields. 

4. (Original) The method of claim 3, wherein said plurality of fields comprises a business 
background field, and wherein said propagating act comprises propagating said business 
background field to each of said sub-focus areas. 

5. (Original) The method of claim 3, wherein said plurality of fields comprises an 
assumptions field which comprises a set of assumptions, and wherein said propagating 
act comprises propagating said assumptions field to each of said sub-focus areas. 

6. (Original) The method of claim 5, wherein said act of propagating said assumptions 
field comprises propagating fewer than all of the assumptions in said set of assumptions. 

7. (Original) The method of claim 3, wherein said plurality of fields comprises a 
functional requirements field, and wherein said propagating act comprises propagating 
said functional requirements field to each of said sub-focus areas. 

8. (Original) The method of claim 3, wherein said plurality of fields comprises a business 
goals field, and wherein said propagating act comprises propagating said business goals 
field to each of said sub-focus areas. 

9. (Original) The method of claim 8, wherein said act of propagating said business goals 
field comprises propagating a sub-goal field. 

10. (Original) The method of claim 3, wherein said plurality of fields comprises a 
business goals field, and wherein at least one of said sub-focus areas is an 
implementation use case, and wherein said propagating act comprises propagating said 
business goals field to each of said one or more focus areas exclusive of said 
implementation use case. 
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11. (Original) The method of claim 1, further comprising: 

specifying a temporal relationship among at least two of said one or more focus 

areas. 

12. (Original) A method for providing computer- assisted software engineering 
comprising: 

receiving first information indicative of a first focus area, said first focus area 
representing: 

a set of first requirements for software to be developed; and 
a set of first participants in the use of said software; 
receiving a division of said set of first requirements which indicates a plurality of 
separate first aspects of said set of first requirement; 

displaying said set of first requirements and said set of first participants; 
receiving second information indicative of a second focus area, said second focus 
area including: 

a set of second requirements for a one of said first aspects; and 
a set of second participants who participate in a use of said one of said 
first aspects, said second set of participants being based on said first set of participants; 

receiving a division of said set of second requirements which indicates a plurality 
of separate second aspects of said set of second requirements; 

displaying said set of second requirements and said set of second participants; 
receiving third information which includes: 

a set of third requirements for a one of said second aspects; and 
a set of third participants who participate in a use of said one of said 
second aspects, each of said third participants having only a single role with respect to 
said one of said second aspects; and 

generating a use case based on said third information, said use case defining an 
instance of the operation of said software by a one of said third participants participating 
in said one of said second aspects. 

13. (Original) The method of claim 12, further comprising: 
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providing a template which comprises a requirements field and a participants 

field; 

and wherein said act of receiving first information comprises: 

storing said set of first requirements in said requirements field; and 
storing said set of first participants in said participants field; 

and wherein said act of receiving second information comprises: 

storing said set of second requirements in said requirements field; and 
storing said set of second participants in said participants field; 

and wherein said act of receiving third information comprises: 

storing said set of third requirements in said requirements field; and 
storing said set of third participants in said participants field. 

14. (Original) The method of claim 12, wherein said method further comprises: 

providing a template which comprises a plurality of fields which represent a use 

case; 

and wherein said generating act comprises: 

displaying said template with at least some of said plurality of fields 
containing information which is based on said third information. 

15. (Original) The method of claim 12, wherein: 

said first information further comprises a set of first assumptions about said 
software to be developed; 

said second information further comprises a set of second assumptions about said 
first aspect; and 

said third information further comprises a set of third assumptions about said 
second aspect. 

16. (Original) The method of claim 12, wherein: 

said first information further comprises a set of first business goals relating to said 
software to be developed; 
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said second information further comprises a set of second business goals relating 
to said first aspect; and 

said third information further comprises a set of third business goals relating to 
said second aspect. 

17. (Original) The method of claim 12, wherein: 

said first information further comprises first business background information 
relating to said software to be developed; 

said second information further comprises second business background 
information relating to said first aspect; and 

said third information further comprises third business background information 
relating to said second aspect. 

18. (Original) A computer-readable medium encoded with computer-executable 
instructions which instruct a computing device to perform a method, the method 
comprising: 

receiving first information indicative of a first focus area, said first focus area 
representing: 

a set of first requirements for software to be developed; and 
a set of first participants in the use of said software; 
receiving a division of said set of first requirements which indicates a plurality of 
separate first aspects of said set of first requirement; 

displaying said set of first requirements and said set of first participants; 
receiving second information indicative of a second focus area, said second focus 
area including: 

a set of second requirements for a one of said first aspects; and 
a set of second participants who participate in a use of said one of said 
first aspects, said second set of participants being based on said first set of participants; 

receiving a division of said set of second requirements which indicates a plurality 
of separate second aspects of said set of second requirements; 

displaying said set of second requirements and said set of second participants; 
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receiving third information which includes: 

a set of third requirements for a one of said second aspects; and 
a set of third participants who participate in a use of said one of said 
second aspects, each of said third participants having only a single role with respect to 
said one of said second aspects; and 

generating a use case based on said third information, said use case defining an 
instance of the operation of said software by a one of said third participants participating 
in said one of said second aspects. 

19. (Original) The computer-readable medium of claim 18 wherein the method further 
comprises: 

providing a template which comprises a requirements field and a participants 

field; 

and wherein said act of receiving first information comprises: 

storing said set of first requirements in said requirements field; and 
storing said set of first participants in said participants field; 

and wherein said act of receiving second information comprises: 

storing said set of second requirements in said requirements field; and 
storing said set of second participants in said participants field; 

and wherein said act of receiving third information comprises: 

storing said set of third requirements in said requirements field; and 
storing said set of third participants in said participants field. 

20. (Original) The computer-readable medium of claim 18, wherein the method further 
comprises: 

providing a template which comprises a plurality of fields which represent a use 

case; 

and wherein said generating act comprises: 

displaying said template with at least some of said plurality of fields 
containing information which is based on said third information. 
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21. (Original) The computer-readable medium of claim 18, wherein: 

said first information further comprises a set of first assumptions about said 
software to be developed; 

said second information further comprises a set of second assumptions about said 
first aspect; and 

said third information further comprises a set of third assumptions about said 
second aspect. 

22. (Original) The computer-readable medium of claim 18, wherein: 

said first information further comprises a set of first business goals relating to said 
software to be developed; 

said second information further comprises a set of second business goals relating 
to said first aspect; and 

said third information further comprises a set of third business goals relating to 
said second aspect. 

23. (Original) The computer-readable medium of claim 18, wherein: 

said first information further comprises first business background information 
relating to said software to be developed; 

said second information further comprises second business background 
information relating to said first aspect; and 

said third information further comprises third business background information 
relating to said second aspect. 
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